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Application # 09/470,566 

Submitted January 14, 2005 

Reply to Office Action of July 1 4, 2004 

m. REMARKS AND AR<?VftffSNTS 

5. The Office Action dated July 1 4, 2004 has been carefully considered. 
Reconsideration of this application, in view of the following remarks, is respectfully requested. 

A* References 

6. The following U.S. patents were considered in the office action: 

• US Patent 5,047,853 ("Hoffert"), filed March 19, 1990. 

• US Patent 6,384,862 ("Brusewitz"), filed March 1 2, 1 997 . 

7. The following U.S. patent applications were also referenced in the office 

action: 

- US Patent Application 09/3 12,922 (the "'922 Application")* 

• This application, US Patent Application 09/470,566 (the "566 
Application"). 

B« Overview of Office Action 

8. The office action ^[1 acknowledges the new oath and declaration claiming 
priority benefits to the '922 Application. 

9. The office action indicates that a declaration that states, "amendatory 
material consists of the same material incorporated by reference" is required. The office action 
further indicates that an election by original presentation should be made regarding 21-24, And 
thus rejected claims 2 1-24 under 35 U.S.C. 1 12. 

10. The office action rejected claims 1-20 as being obvious in light of Hoffert 
in combination with Brusewitz under 35 U.S.C. 103(a). 
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C. Declaration Regarding Amendatory Material 

1 L On page 2 of this paper, I have made another declaration regarding the 
May 3, 2004 amendment which states that the "amendatory material consists of the same 
material incorporated by reference" and that "no new matter was added/' 1 Applicant respectfully 
submits that the response is now complete, and requests that the amendatory material including 
claims 21-24 be fully considered. 

D. Consideration of Claims 21-24 

12. Claims 21-24 contain the same language as claims 28-3 1 of the 6 922 
Application. Claims 28-3 1 of the '922 Application have been cancelled in the *922 Application, 
and have been moved from the '922 Application to this the '566 Application . When they were 
moved to this application they were renumbered as 2 1 -24. This has been communicated 
previously, for example, (paper no 9, page 1 7„ section E). 2 

E. Claims 21-24 Not Divergent 

13. Claims 21-24 are directed to the same subject matter as the other pending 
claims. Claim 21 is directed toward a compression method includes steps found in claim 1 . 
Both Claim 1 and 21 select "a code based on a number of bits from each pixel" and then "run- 
length encod[e] repeated instances of said code." Claim 21 uses different terminology but 
describes the same steps, Both Claim 1 and 21 work on "each pixel". The "current line number" 
is a "code based on a number of bits from each pixel". If the "current line number" (code) 

1 Mote this declaration was made previously in the May 3 ? 2004 reply. See ^1 1 on page 3 of 4. "I hereby 
declare that the amendatory material consists of the same material incorporated by reference. No new matter has 
been added." 

2 "Note thai claims 21 through 24 are the same as claims 28 through 3 1 that were submitted on 1 7 May 
1999 with application 09/3 12,922 (with the correction of an obvious error in claim 28(c) now claim 23 (c)." (Page 
17, January 13, 2003 Amendment) 
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"matches a previous line number of an immediately prior pixel" (i.e, is a "repeated instance" of 
the code), the "repeat counter" is incremented and M a repeat data structure with the repeat 
counter" is encoded, thus "run-length encoding repeated instances of the said code". In both 
Claim 1 and 2 1 the encoded data forms a compressed "stream" of data (i.e. a buffer that is 
streamed), 

14. Thus, claim 21 is not divergent from claim 1 . Claims 22-24 are dependent 
on claim 2 1 and for the same reasons do not diverge from the other pending claims. Claim 24 
adds decompression steps which claim the same subject matter as found in claim 8. Applicant 
submits that claims 2 1 -24 are not divergent and no restriction or election is required. , 

1 5. Note: The amended specification contains a section (see pages 9 through 
1 1) that correlates the terminology used in claims 1-20 with the terminology used in claims 21- 
24. This information should aid the examiner and others in understanding the correlation. 

F. Claim Rejections under 35 U-S.C. 112 

16. The office action at f3 rejected claims 21-24 under 35 U.S.C. 1 12 "as 
containing subject matter which was not described in the specification in such as way as to 
reasonable convey to one skilled in the relevant art that the inventors), at the time of the 
application was filed, had possession of the claimed inventions." Applicant submits that the 
declaration regarding the amendatory matter is sufficient to overcome this rejection. 

17. Further, Applicant points out that this, the '566 Application, claims 
priority based on the US Patent Application 60/1 1 3,276 filed December 23, 1 998 (the "276 
Application"), and based on the '922 Application which was filed on May 17, 1999. The May 
17, 1999 filing (which included the language of current claims 21-24) clear shows that the 
inventors had possession of the invention as claimed in claims 21-24, This '566 application was 

Page 11 of 21 



L T 



3868Be^80V 



*oui aujejjexpauj 



WdTS=9 £002 i-T uef 



tC-u:(ss-uiui) NOUVUna « eS886CZ80^:aiS3 * 90C6eZ8:siNQ « Z/l>-dUXJ3-01dSn:tfAS « lewil pjepuejs uiajsea] Wd XZ'-Wl SQOZMtl 1VOA3U « LZm 30Vd 



Application # 09/470,566 

Submitted January 14, 2005 

Reply to Office Action of July 14, 2004 

filed December 22, 1999 and contains drawings that support the subject claimed by claim 21-24. 
Compare encode tables found on page 5 of the '276 Application, Fig 3A of the '922 Application, 
and Fig 3 A of this *566 Application. Likewise compare the decode tables found on page 6 of the 
•276 Application, Fig 7 of the '922 Application, and Fig 7 of this '566 Application. The 
compression and decompression flow charts also show that the invention (as claimed by claim 
21-24) was in our possession at least as early as December 23, 1998 and the specific terminology 
was used to describe these methods in the May 17, 1999, filing. Both of these show 'that the 
inventor(s), at the time of the application was filed, had possession of the claimed invention". 
G. Claim Rejections under 35 U.S.C. 103 

18. The office action rejected claims 1-20 as being obvious in light of Hoffert 

in combination with Brusewitz under 35 U.S.C. 103(a). 

Hoffert Does Not Teach "selecting a code based on a number of bits from 
each pixel" 

19. The office action, after 12 states "Hoffert '853 teaches (i.e. col. 6, lines 22- 
55) selecting a type of encoding based on the luminance associated with each pixel with respect 
to [a] mean pixel valued, which meets the limitation as claimed." Applicant disagrees. The 
office action misunderstands Hoffert; it does not teach what the examiner relies upon it as 
supposedly teaching. The office action relies on Fig 2 for teaching applicant's "selecting a code 
based on a number of bits from each pixel selected from said pixels", 

20. Hoffert teaches selecting type of encoding from a group of four binary 
*tt£*:j'.* -codes, i.e. 00, 01, 10, and 1 1 (see Hoffert Fig. 2). The cited reference (Hoffert 6:22-55) 

* describes the 00 coding and the 10 coding types. The 00 code represents a block of 16 pixels 
which each have the same color, i.e. "4x4 pixel block of one color 5 ' (Hoffert, Fig 2). The 10 
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code also represents a block of 16 pixels which have "one of two diverse colors" (Hoffert 6:46) 
where the "data for the block is stored as two colors and a single 16 bit map. .." (Hoffert 6:35- 
36), i.e. "block of two colors" 

21 . There is a number of distinctions between Hoffert and the claim language 
"selecting a code based on a number of bits from each pixel": 

• Hoffert 3 s method is block based not pixel based 

• Hoffert has one code for each block, not a code for each pixel 

• Hoffert does not select a code based on a number of bits from pixel 

• Hoffert' s codes specify a type of encoding that does not vary based on pixel value 
Each of these distinctions will be discussed farther in the following sections. 

Hoffert's Method is Block Based not Pixel Based 

22. Hoffert, like many conventional compression algorithms is block based. 
Hoffert works on blocks of sixteen pixels in 4 x 4 blocks. Before Hoffert's compression method 
can even start at least four lines of the image must be received. "In order for this to be 
implemented, buffering is used to store four scan lines of pixel data so that 4x4 blocks can then 
be considered." (Hoffert 3 :25-27) Applicant's method is pixel based. Hoffert teaches away from 
pixel based compression. This major distinction alone should overcome the obviousness 
argument. Because applicant's method is pixel-based it can determine a code as soon as few as 
two pixels (for example, in a 640x480 image) have been received. Hoffert in contrast would 
have to receive the whole images (or at least four lines of the images which could be thousands 

COL 

of pixels, eg. 640 x 4 = 2560 pixels). In this example, only after receive thousands of pixels 
could Hoffert break them into blocks and start processing the blocks. 
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Hoffert Has One Code for Each Block, not a Code for Each Pixel 

23 . Close reading of Hoffert will show another distinction. Hoffert will only 
select one code per each block of 1 6 pixels. In contrast, Applicant's invention will select a code 
for each pixel. Thus, Hoffert does not teach the limitation as claimed 

Hoffert Does Not Select a Code Based on a Number of Bits from Each Pixel 

24. Applicant's invention selects a code that based on a number of bits 

selected from each pixel. The code is directly related to the pixel value, either through extraction 

(e.g, claim 4, Fig 2D-2F, Fig 8) or through table lookup (e.g. claim 5, Fig 3A-3B). In claim 4, 

"the number of bits is five and said code is determined by extracting the five most significant bits 

from each pixel". In claim 5, "the number of bits is five and said code is obtained from an 

encode table." In claim 1 5, the "pixel values" are directly related to the code values. Hoffert 

simply does not teach that the code is "based on a number of bits from each pixel". Instead 

Hoffert teaches a code that is unrelated to the values of the bits from each pixel but is based on 

the determination of a single color for the block, a determination of two colors for a block, and 

so forth. Thus, Hoffert does not teach tlie limitation as claimed 

Hoffert 's Codes Specify a Type of Encoding That Does Not Vary Based on 
Pixel Value, 

25. Applicant's invention selects a code that based on a number of bits 
selected from each pixel (claim 1) and on a pixel value (claim 15). In contrast, Hoffert teaches 
only four binary codes, where is code specifies a type of encoding, not the value of the pixel bits. 
A 00 code will be used when all 16 pixels have the same color, for example black (all the bits are 

k- l^ie. 111111111111111111111111). The same 00 code will be used when all the 16 pixels 
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have the same white color (all the bits are 0s, i.e. 000000000000000000000000). Thus the 00 
code is not based on the value of the pixel. 

26. Applicant's invention works differently. In the claim 5 embodiment, in 
reference to Fig 3 A, a black pixel (i.e. 111111111111111111111111) would be reduced to 8 bits 
(i.e. 11111111 binary or 255 decimal, see e.g. Fig 2G and 2H) and would result in a code of five 
bit code (i.e. 3 1 decimal) (last line of Fig 3A, line 31 of Fig 3B). The code is directly related to 
the pixel value in this case through table lookup. Further, a white pixel (i.e. 
000000000000000000000000) would be reduced to 8 bits (i.e. 00000000 binary or 0 decimal, 
and would result in a code of five bit code (i.e. 0 decimal) (first line of Fig 3 A, line 0 of Fig 3B). 
Thus a black pixel value would result in a code of 3 1 and a white pixel value would result in a 
code of 0. This is what is meant by the limitation "selecting a code based on a number of bits 
from each pixel." Hqffert does not teach this. Instead Hoffert teaches that the same code 00 will 
be selected regardless of the value of a "number of bits for each pixel" (claim 1) or "pixel value" 
codes (claim 1 5). Tn this regard Hoffert teaches away from the claimed invention. Thus, Hqffert 
does not teach the limitation as claimed. 

Claim 1 Not Made Obvious by Hoffert in View of Brusewitz 

27. As stated above Hoffert does not teach "selecting a code based on a 
number of bits from each pixel". 

28. Further, Hoffert does not teach "run-length encoding repeated instances of 
said code." The office action cites Hoffert Fig 10, 107 as teaching this claim element. The cited 
figure is a "run-length decrementer", While this uses the word run-length, it fails to teach "run 
length encoding" as required by the claim. Further, it fails to teach the full claim limitation, 
namely, "run-length encoding repeated instances of said code". Said code refers to the "code 
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based on a number of bits from each pixel" which, as explained above Hoffert does not teach. 
Hoffert cannot teach run-length encoding of "said code 9 ' because it does not teach said code. 
Instead Hoffert teaches run-length encoding of multiple ["Blocks of same color (run length 
blocks)" Fig 2, 01], In this regard Hoffert teaches away from the limitation as claimed. 

29. Further, Hoffert does not teach "repeating steps (b) and (c) until each said 
pixel is encoded." As discussed above, Hoffert does not perform its steps on pixels but on blocks 
of pixels. Therefore Hoffert does not teach repeating the pixel-based steps, 

30. Further, the office action states "streaming buffer is an inherent feature 
necessitated by the digital video processing". The use of an "encoded data buffer" to hold all of 
the encoded data for an entire image is not inherent. In fact, many of the conventional block 
based compression methods, store only a block, or subset of blocks, from an image and then 
stream the encoded data for less than a block. Alternatively, a fixed sized buffer can be used, 
which is only stared or transmitted when the buffer is fuU. In this alternative, multiple images 
may be stored in the buffer before the buffer is streamed. Hoffert does not teach this claim 
limitation and it is not inherent. 

3 1 . Hoffert does not teach "sub-sampling pixels from an image". The office 
action relies on Brusewitz for this teaching, citing Brusewitz Fig 1, sub-sampler 20, 1:41+. The 
office action has not clearly indicated the basis of this teaching. The subsampler 18 in Fig. 1 is 
not part of the encoder 20 and thus is not part of the compression method. 

32. Thus, if the teaching of Hoffert were combined with Brusewitz, it would 
not result in the claimed invention, because, as discussed above, Hoffert does not teach many of 

the claimed elements. *^vimm*> * *h:^v 
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Combination of Hoffert and Brusewitz is Improper 

33. As explained above, in my January 1 3, 2003, Amendment, 

• Hoffert and Bruzewitz teach away from the present invention. 

• Hoffert and Bruzewitz combined do not teach the invention. 

• Hoffert and Bruzewitz do not contain any justification to support their combination, much 
less in the manner proposed. The references themselves must suggest that they be combined 
(In re Senaker). There must be some reason for the combination other than hindsight gleaned 
from applicant's invention- (Uniroyal, Inc. v. Rudkin- Wiley Corp.) 

• Hoffert and Bruzewitz are individually complete. 

• Hoffert and Bruzewitz are from different fields as evidence by different US classes and fields 
of search. 

Claim IS Not Made Obvious by Hoffert in View of Brusewitz 

34. As stated above in regard to claim 1 Hoffert in view of Brusewitz fail to 
teach the limitations of claim 1 . The office action failed to provide a separate analysis of claim 
15. As discussed above, claim 15 has different limitations, such as "a video digitizer", a 4 Video 
memory", "run length encoding circuit for counting repeated instances of a pixel value when 
scanning". 

35. Neither Hoffert nor Brusewitz teach "counting repeated instances of a 
pixel value when scanning". As discussed above, because Hoffert teaches away from processing 
pixels t4 when scanning." Instead Hoffert teaches "In order for this to be implemented, buffering 
is used to store fou&scanJines of pixel data so that 4x4 blocks can then be considered." (Hoffert 
3:25-27) Hoffert fails to teach this claim liraitiation and instead teaches that the pixels should be 
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processed as blocks after scanning is complete. This is a major distinction between Applicant's 
invention and the conventional block-based compression methods. 

Claims 2 and 3 Not Made Obvious by Hoffert in View of Brusewitz 

36. Claims 2 and 3 are dependent on claim 1 and, therefore claims 2 and 3 
should be patentable for all the reasons stated in relation to claim 1 . 

Claims 4 and 5 Not Made Obvious by Hoffert in View of Brusewitz 

37. Claims 4 and 5 are dependent on claim 1 and, therefore claims 4 and 5 
should be patentable for all the reasons stated in relation to claim 1 . 

38. Further, as discussed above Hoffert does not teach "a number of bits from 
each pixel"; therefore Hoffert cannot teach that "said number of bits is five". The office action 
failed to provide a basis for a rejection for the limitations where "said code is determined by 
extracting the five most significant bits form each pixel" (claim 4) and where "said code is 
obtained from an encode table" (claim 5). Neither Hoffert nor Bruswitz teach these claim 
limitations. 

Claims 6 and 7 Not Made Obvious by Hoffert in View of Brusewitz 

39. Claims 6 and 7 are dependent on claim 6 (either directly or indirectly) and, 
therefore claims 6 and 7 should be patentable for all the reasons stated in relation to claim 1 . 

40. The office action cites to Hoffert Fig 1 to teach "an encoded video signal 
comprises a series of said encoded data buffers." Hoffert Fig 1 is a single word showing the 
adapting coding format. Hoffert fails to teach a "series of said encoded data buffers 1 ' where each 
"encoded data buffer" contains the encoded data for an image (claim I). 

41. The office action cites to Brusewitz Fig 1, 22 and 30 5 to teach "an encoded 
video signal comprising] a series of said encoded data buffers." Brusewitz Fig 1, 22 and 30 
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show two boxes labeled "buffer". However, these are not "a series of said encoded data 
buffers". Brusewitz teaches that "control unit 24 also governs the variable bit rate of the 
information flow into buffer 22 to maintain a particular data level and avoid both overflow and 
underflow therein," (Brusewitz 2:29-32) and "As is understood in this art, the primary purpose of 
buffer 22 is to regulate the flow of data from the encoder 20 and forward that data at a fixed rate 
across a transmission channel 26 to a receiver device 28, particularly, to another buffer 30 
therein, which like buffer 22 acts as a reservoir storing the data and regulating its use." 
(Brusewitz 2:33-37) 

42. There are two meanings of the word "buffer" as used in the art. The first 
meaning as used by Brusewitz, which is "a circuit or device that is put between two others to 
smooth changes in rate or level or allow asynchronous operation" (Oxford Dictionary of 
Computing, 1997). The second is the meaning used by many C programmers, which is "an area 
of memory" or "an array of bytes*'. For example, Microsoft teaches "Buffer manipulation 
routines [e.g. memcopy and memset] are used with areas of memory on a character-by-character 
basis. Buffers are arrays of characters (bytes)." (pp. 345-346, C for Yourself, 1990). Having 
programmed an embodiment of the invention in the C programming language, in drafting the 
claims, I used and intended the second meaning and not the first. Thus the term "encoded data 
buffer 5 * should be understood to mean "an array of bytes containing the encoded data for an 
image". Brusewitz fails to teach a "series of said encoded data buffers" where each "encoded 
data buffer" contains the encoded data for an image. In this regard, Brusewitz teaches away 
from Applicant's invention, in that Brusewitz teaches flow control type buffering. 
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Claim 8 Not Made Obvious by Hoffert in View of Brusewitz 

43. Claim 8 is the decompression part of claim 1 * Since neither Hoffert nor 
Brusewitz, nor their combination teach the compression of claim 1, they likewise fail to teach the 
decompression of claim 1 . 

Claims 9-12 and 19-20 Not Made Obvious by Hoffert in View of Brusewitz 

44. The office action rejects claims 9-12 and 19-20 based on their similarity to 
claims 2-5, 8, and 15. For all the reasons stated in regard to claims 2-5, 8, and 15, claims 9-12 
and 19-20 are not made obvious by Hoffert and Brusewitz. 

Claims 13-14 and 16 Not Made Obvious by Hoffert in View of Brusewitz 

45. The office action rejects claims 13-14 and 16 based on the four binary 
codes in Hoffert (Fig 2, and Fig 3 1 9, 23, 25, 29, and 33). As discussed at length at the top of 
this section above, these codes are not the same as Applicant's codes that are based on the bits 
that indicate the pixel value. Therefore, Hoffert does not teach the applicant's encode table, 
decode table, or encryption table. 

Claims 17 and 18 Not Made Obvious by Hoffert in View of Brusewitz 

46. Claims 1 7 and 1 8 are dependent on claim 1 5 and, therefore claims 1 7 and 

1 8 should be patentable for all the reasons stated in relation to claim 1 5. 

, t ,_.„ . Claims 21 through 24 Not Anticipated or Made Obvious by Hoffert in View 
of Brusewitz 

47. As discussed above claim 2 1 is directed to the same subject matter as 
claim L Claims 22 through 24 are dependent on claim 21 . Therefore claims 21 through. 24 
should be patentable for all the reasons stated above in relation to claims 1-20. 
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IV. New Claims 

48. Claims 25-37 are presented with this amendment Claim 25 covers the 
same scope as claim 1 and claims 26-37 are depended on claim 25. Therefore, these claims 
should not require an election or restriction. 

49. Claims 25-37 are presented to more distinctly claim the subject matter. 
No new matter is added These claims are not being added to overcome prior art 

50. Applicant submits that claims 25-37 are.patentable as written. 

V. Reconsideration Requested 

5 1 . The undersigned respectfully submits that, in view of the earlier response 
and the foregoing remarks, the rejections of the claims raised in the Office Action have been 
fully addressed and overcome, and the present application is believed to be in condition for 
allowance- It is respectfully requested that this application be reconsidered, that these claims be 
allowed, and that this case be passed to issue. If it is believed that a telephone conversation 
would expedite the prosecution of the present application, or clarify matters with regard to its 
allowance, the Examiner is invited to call the undersigned inventor at 408-739-95 1 7. 



Respectfully submitted, 




Kendyl A. Roman 

Phone:408-739-9517 

Date: January 14 5 2004 
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